The creation of a system and/or software generally entails a development process that includes the specification of requirements and the testing of those requirements against for example, various versions of the software in order to arrive at software having the desired characteristics. A requirement can be thought of as a condition, capability, and/or attribute which the system or software being developed should conform to or contain. Requirements can be specified by a developer or an end-user of the system or software, business policies, and/or any other entity or source having a need for such conditions, capabilities, and/or attributes to be present in the system or software.
Additionally, during the lifetime of a system or software, new requirements can be created, old requirements can be deleted, and current requirements can be updated or otherwise modified. The process of handling requirements during the lifetime of a system or software, e.g., codifying the requirements, verifying the requirements, tracking the requirements, documenting the requirements, auditing the requirements, traceability of the requirements, etc., is generally referred to as requirements management. Thus, requirements management comprises a systematic approach to eliciting, organizing, and documenting system and/or software requirements, and a process which establishes and maintains agreement between a customer and a project team regarding evolving requirements of the system and/or software.
As described above, during the development life cycle of a system or software, requirements are tested against different versions or releases of the system or the software. Testing is done to ensure that the new requirements are implemented correctly, as well as operate correctly when the requirement is tied to a system or software feature.
In order to test the requirements, as described above, a mechanism is needed to synchronize the requirements between where the requirements are stored and the testing environment. Conventional synchronizing applications are very limited in functionality, giving rise to various problems associated with the requirements management and the requirements testing processes. Consider for example, a situation where a test group is currently testing requirements associated with a software release 1.0, where the requirements have been received from a requirements store. Consider as well that a development group has released a new version of the software, i.e., software release 1.1 that contains new software code and has new requirements associated therewith, where the new requirements are uploaded into the requirements store. When a conventional synchronizing application is used to synchronize the new requirements with a testing environment, the new requirements will be blindly updated in the associated testing environment without notifying the test group that new requirements have been uploaded, effectively replacing the requirements currently being tested. Therefore, remaining requirements of software release 1.0 not yet tested will remain untested. In addition, traceability among the same or the same type of requirements between different software releases is lost, creating for example, a situation where it is impossible to determine whether it is software code in release 1.0 or release 1.1 that caused a defect associated with one or more requirements.
In addition, conventional synchronizing applications lack any true configurability or control that can be exercised by a tester or test group. For example, conventional synchronizing applications are typically implemented on one or more servers, thus forcing a tester or test group to access the server to modify any parameters related to the synchronization process. Furthermore, there is no control regarding whether all of the requirements associated with, for example, a software release are to be synchronized with the testing application or only a subset of the requirements are to be synchronized. Also, considering that requirements are synched between the two applications, it would be advantageous to also provide validation and/or authorization processes at the synchronization application to avoid unauthorized or otherwise improper movement of requirements to the testing repository.
Moreover, as described above, any requirements relationships and hierarchies that have been defined and/or identified should be maintained, whereas the conventional synchronizing applications have no mechanism for maintaining those relationships and hierarchies once the relevant requirements are sent to the testing environment. Thus relevant information which might aid testers and test groups in properly and meaningfully testing requirements is lost.